In the third generation wireless communication standards, various application service entities use a generic framework for accomplishing user identity authentication, which is referred to as the Generic Authentication Architecture (GAA). An application of the generic authentication architecture can check and authenticate the identity of a user of an application service and provide the user accessing the application service with a key for secured communication. The various application service can include a multicast or broadcast service, a user certificate service, an instant messaging service, etc., or a proxy service.
FIG. 1 illustrates a schematic diagram of a framework of the GAA.
The generic authentication architecture is typically consisted of a User Equipment (UE), an entity of Bootstrapping Server Function (BSF) which initially checks and authenticates the identity of a user, a Home Subscriber Server (HSS), an entity of Subscriber Locator Function (SLF) which locates the HSS, and an entity of Network Application Function (NAF). The BSF is used for mutual identity authentication with the UE and also for generation of a shared key, Ks, which the BSF shares with the user, and the HSS stores therein a description file which describes user information and also functions to generate authentication information. Dz, Zh, Zn, Ub and Ua each denote an interface between the respective entities.
Usually, the UE intending to access a service is required to contact the NAF corresponding to the service, that is, the UE is required to initiate actively a connection request to the NAF. If the NAF uses the Generic Authentication Architecture GAA, then the UE is firstly required to perform mutual authentication with the BSF for identity authentication. Upon successful authentication, the UE calculates a derived key Ks_NAF for encrypted communication with the NAF from the key Ks shared with the BSF and transmits a Bootstrapping Session Transaction Identifier (B-TID) to the NAF, and the NAF obtains from BSF the derived key Ks_NAF of the shared key Ks according to the received B-TID. Thus, the UE and the NAF can make use of the derived key Ks_NAF for secured communication via the interface Ua.
The network side is required in some application scenarios to initiate actively a communication request to the UE, which is referred to as a push service. An existing GAA push flow is as follows.
The NAF is firstly required to request the BSF for the derived key Ks_NAF of Ks for communication via the interface Ua prior to transmission of a push message to the user by using the GAA technology.
If the BSF has not negotiated with the UE about any available shared key Ks upon reception of the key request of the NAF, then the BSF acquires a set of authentication vectors from the HSS and calculates Ks and Ks_NAF and transmits to the NAF an authentication token (AUTN) in the set of authentication vectors and the derived key Ks_NAF and also possibly a random number (RAND), a Bootstrapping Session Transaction Identifier (B-TID), a lifetime of the derived key Ks_NAF in the authentication vectors, etc. Then, the NAF transmits, in a push message transmitted to the UE, the information of AUTN, RAND, B-TID, NAF Identifier (NAF_ID), etc., and also possibly encrypted data. The UE authenticates the network and calculates the shared key Ks and the derived key Ks_NAF in accordance with the values of AUTN and RAND.
If the BSF has negotiated with the UE about the available shared key Ks upon reception of the key request of the NAF, then the BSF calculates the derived key Ks_NAF from the shared key Ks and transmits the corresponding B-TID and lifetime of Ks_NAF to the NAF. The NAF carries the B-TID and NAF-ID and also possibly encrypted data in a push message transmitted to the UE. The UE calculates the derived key Ks_NAF from the shared key Ks in the B-TID or searches locally for a Ks_NAF corresponding to the B-TID and uses the key to decrypt the carried encrypted data.
In the case of the UICC based Generic Bootstrapping Authentication architecture (GBA_U), the BSF and the UE may derive two keys from the shared key Ks, i.e., the derived key Ks_int_NAF put on a Universal Integrated Circuit Card (UICC) and the derived key Ks_ext_NAF put on a Mobile Equipment (ME). In this case, the NAF is required to negotiate with the UE about a key to be used for secured communication.
In a UE initiated service, the UE side decides the derived key for use in accordance with the location of an application: if it is a UICC based application, then the derived key Ks_int_NAF put on the UICC is used; and if it is an ME based application, then the derived key Ks_ext_NAF put on the ME is used. Then, the UE notifies the NAF about the selected type of key by indicating to the NAF the location where the application resides. The NAF then determines whether to allow a type of key selected by the terminal in accordance with a local policy or with a policy of the BSF. If it is allowed, then the key is used for communication; otherwise the request of the UE is rejected.
However in the push service, there is no message transmitted between the NAF and the UE before the NAF transmits the push message to the UE. Even in some cases, the UE may not be provided with a feedback channel for transmission of a message to the network side at all. It is thus impossible for the UE to notify the network side about a type of key as it selects. Consequently, this existing approach cannot be applicable in the GAA push process.